Hi,
in my code, I have this line:
eTrigger = trigger(module, close, 10, closeModuleTrig)
What does this line do?
After I have tried to replace "module" to a specified module in that way:
Module myCurrentModule;
myCurrentModule = read(fullName(i), false, true)
eTrigger = trigger(myCurrentModule, close, 10, closeModuleTrig)
tobi_mehrl - Wed Jun 10 03:09:51 EDT 2015
Re: What does this statement?
Wolfgang Uhr - Wed Jun 10 03:19:39 EDT 2015
Hi
Why don't you open the dxl-help file to search for trigger?
Best regards
Wolfgang
Re: What does this statement?
tobi_mehrl - Wed Jun 10 03:27:04 EDT 2015
I have a dxl reference manual and I also opened this manual. The problem is, that in this manual ist not exactly and for me understandable explained. The manual says:
trigger(dynamic):
Creates a dynamic trigger, which is not persistent between sessions, at level
l, of event e and priority p. The pre callback function determines whether the operation happens or not. The callback function for a post event is a void function.
Optionally, the level can be a compound level description.
Now my question: "What does this trigger()-function???"
Re: What does this statement?
Wolfgang Uhr - Wed Jun 10 04:05:17 EDT 2015
tobi_mehrl - Wed Jun 10 03:27:04 EDT 2015
I have a dxl reference manual and I also opened this manual. The problem is, that in this manual ist not exactly and for me understandable explained. The manual says:
trigger(dynamic):
Creates a dynamic trigger, which is not persistent between sessions, at level
l, of event e and priority p. The pre callback function determines whether the operation happens or not. The callback function for a post event is a void function.
Optionally, the level can be a compound level description.
Now my question: "What does this trigger()-function???"
There is a chapter "Introduction to triggers"
Re: What does this statement?
GregM_dxler - Wed Jun 10 10:52:15 EDT 2015
tobi_mehrl - Wed Jun 10 03:27:04 EDT 2015
I have a dxl reference manual and I also opened this manual. The problem is, that in this manual ist not exactly and for me understandable explained. The manual says:
trigger(dynamic):
Creates a dynamic trigger, which is not persistent between sessions, at level
l, of event e and priority p. The pre callback function determines whether the operation happens or not. The callback function for a post event is a void function.
Optionally, the level can be a compound level description.
Now my question: "What does this trigger()-function???"
Hi,
The trigger information in the dxl manual is a little cryptic. For your code
eTrigger = trigger(module, close, 10, closeModuleTrig)
This makes a trigger where when a module is closed, it will execute the dxl code closeModuleTrig.dxl.
Hopefully you have that code handy to see what it does, as it doesn't look like a library function.
The 10 is a priority value and is only meaningful when there are multiple triggers.
Hope this helps,
Greg
Re: What does this statement?
llandale - Sat Jun 27 16:41:47 EDT 2015
Yes the manual is weak, and while the Trigger section is quite a bit above average, triggers are difficult to grasp.
Triggers are the trickiest thing in DXL and the most dangerous. You must practice on some replaceable scratch database and should have someone review and test them for you. Expect to get very frustrated. Some of the best DXL folks in the world snapped over triggers, and are now writing Excel formulas with crayons.
Triggers:
Triggers run DXL code on a DOORS Client when an event is detected. The DOORS Service cannot be made to run Triggers. No trigger fires when nothing is going on. There is no native GUI for triggers. If you want to associate some code with an event you must write some other code to do the association; or "define the trigger". Such definition code is better written to allow for removing (delete) the trigger and also for defining (adding) the trigger. Without that it is very difficult to "delete" a trigger.
Class:
Triggers can be either "stored" or "dynamic" (lets forget about "builtin"). Stored Triggers are written to the database and will be there the next time. Dynamic triggers are NOT stored in the database and exist until deleted or you close your DOORS client session; or you close the module in which they are defined. Nobody else is affected by any dynamic trigger you define. Dynamic triggers are often used to close a dialog box when you close the associated module. I have only used "module" level Dynamic triggers, I don't know what a "database" or "project" level one would be like.
Note that "Dynamic" trigger code is in the form of a function call while "Stored" triggers are in the form of a DXL string.
Levels:
"Level" is combined with "Scope" when defining triggers.
Trigger "level" has two meanings:
[1] the sort of thing associated with an event (module, object, attribute, discussion, and comment). e.g. An "Attribute" level trigger means you are writing a trigger to fire when something happens to an Attribute. "Scope" says which attributes.
[2] where the Trigger is stored. "Scope" decides where the Triggers can be stored, in a Module, a Project, or in the Database. (Not a Folder). If the trigger fires for only one module it is stored in that module. If it affects more than one module in a Project then it is stored in that Project. More than one Project then in the Database.
so a "Project->module->all->attribute" trigger is stored in the current Project.
Frankly, I still have to work through that tediously to figure it out.
In my long experience I have found that maintaining Triggers in the Project (or sometimes the database) is far easier than in many Modules. The trigger needs to be written so if figures out which module is firing it and decides if it wishes to continue or not. So a trigger to do something with "Spec" modules would figure out if the current module is a "Spec", and if not just stop.
Event
What happens to fire the trigger, (open, close, save, sync, drag, drop, create). Each Event is associated with only some of the Levels; see the chart in the manual. Notice you cannot have a "sync" trigger for a "Discussion" nor can you have a "save" trigger for a "Module". Notice that while you can store Triggers in Projects, there are no longer triggers associated with the Project. Long time ago there were Project Open/Close triggers.
Type
Type is when the trigger fires relative to the event, either "pre" (before) or "post" (after). A "pre" trigger is allowed to prevent the event; a "post" trigger happens after the event.
Generally, "pre" triggers are used to prevent certain events are far less commonly to do something else useful.
Generally, "post" triggers are used to do something useful.
Just about all DXL folks new to triggers end up writing a "pre module open" trigger that disallows the module from opening. Doh! That is a drag since the trigger is typically stored IN the module and it is difficult to remove until the module is opened. I went through this particular "right-of-passage" a few times.
Notice that a "pre module open" trigger does not have access to the "Module" since it is not yet open; and a post module close trigger no longer has access to the "Module" handle.
Typical "pre" triggers are pre-attribute-save triggers, preventing unauthorized changes to certain object-attribute values. In fact, this method of "locking down values" is far easier to manage than attempting to manage Object and Attribute-Value accesses. The trigger figures out if the value is locked down and whether you have rights, and prevents or allows accordingly.Note that pre-Dynamic triggers require a function that returns a boolen (permission for the event to occur) while post-Dynamic triggers use function with a void return.
Pre-Stored triggers use the "set(TriggerStatus)" function to allow or prevent triggers. I like this structure for pre-stored triggers:
- set (trigPreConPass) // event is allowed unless we figure out it should not below
- bla bla bla
- if (for whatever reason I want to prevent the event ) then set(trigPreConFail)
Priority
Not too useful, decides which trigger fires first when a single event will fire more than one trigger.
Unique
I think a trigger is "unique" based on its name and all its characteristics except the DXL. So if a pre-attr-save trigger priority 5 named "XZY" stored in Project X exists, you cannot create a new one. This has some implications on your definition code.
Manipulation
Some of the functions that take a Trigger parameter work when you are inspecting the trigger; others only work while the trigger is running. The manual does not clarify which is which. You can get the string scope(Trigger) when it is not running in the Definition code (or some other code) but can get the Object object(Trigger) inside the trigger code itself.
-Louie
Notes:
- Stored triggers require "C" access to the module or folder; removing requires "D" access.
- You cannot "modify" a trigger. You must delete it and then add it.
- On a side note: I don't recall the details but I had some serious issues with Triggers stored in a Project when that Project was subsequently converted into a Folder; or perhaps when it was converted back. I also had some issues when nested Projects each had defined triggers. I may have had some issues with restoring Projects with triggers defined.
- You can "turn triggers off" such that they do not fire; but they still fire unless the user is a DB-Admin. turning off does not prevent defining and deleting them.
- You will need to write some generic code that will find triggers and let you remove them individually; as often the original definition code turns up missing.
Re: What does this statement?
smarti.sj - Mon Jun 29 08:56:21 EDT 2015
llandale - Sat Jun 27 16:41:47 EDT 2015
Yes the manual is weak, and while the Trigger section is quite a bit above average, triggers are difficult to grasp.
Triggers are the trickiest thing in DXL and the most dangerous. You must practice on some replaceable scratch database and should have someone review and test them for you. Expect to get very frustrated. Some of the best DXL folks in the world snapped over triggers, and are now writing Excel formulas with crayons.
Triggers:
Triggers run DXL code on a DOORS Client when an event is detected. The DOORS Service cannot be made to run Triggers. No trigger fires when nothing is going on. There is no native GUI for triggers. If you want to associate some code with an event you must write some other code to do the association; or "define the trigger". Such definition code is better written to allow for removing (delete) the trigger and also for defining (adding) the trigger. Without that it is very difficult to "delete" a trigger.
Class:
Triggers can be either "stored" or "dynamic" (lets forget about "builtin"). Stored Triggers are written to the database and will be there the next time. Dynamic triggers are NOT stored in the database and exist until deleted or you close your DOORS client session; or you close the module in which they are defined. Nobody else is affected by any dynamic trigger you define. Dynamic triggers are often used to close a dialog box when you close the associated module. I have only used "module" level Dynamic triggers, I don't know what a "database" or "project" level one would be like.
Note that "Dynamic" trigger code is in the form of a function call while "Stored" triggers are in the form of a DXL string.
Levels:
"Level" is combined with "Scope" when defining triggers.
Trigger "level" has two meanings:
[1] the sort of thing associated with an event (module, object, attribute, discussion, and comment). e.g. An "Attribute" level trigger means you are writing a trigger to fire when something happens to an Attribute. "Scope" says which attributes.
[2] where the Trigger is stored. "Scope" decides where the Triggers can be stored, in a Module, a Project, or in the Database. (Not a Folder). If the trigger fires for only one module it is stored in that module. If it affects more than one module in a Project then it is stored in that Project. More than one Project then in the Database.
so a "Project->module->all->attribute" trigger is stored in the current Project.
Frankly, I still have to work through that tediously to figure it out.
In my long experience I have found that maintaining Triggers in the Project (or sometimes the database) is far easier than in many Modules. The trigger needs to be written so if figures out which module is firing it and decides if it wishes to continue or not. So a trigger to do something with "Spec" modules would figure out if the current module is a "Spec", and if not just stop.
Event
What happens to fire the trigger, (open, close, save, sync, drag, drop, create). Each Event is associated with only some of the Levels; see the chart in the manual. Notice you cannot have a "sync" trigger for a "Discussion" nor can you have a "save" trigger for a "Module". Notice that while you can store Triggers in Projects, there are no longer triggers associated with the Project. Long time ago there were Project Open/Close triggers.
Type
Type is when the trigger fires relative to the event, either "pre" (before) or "post" (after). A "pre" trigger is allowed to prevent the event; a "post" trigger happens after the event.
Generally, "pre" triggers are used to prevent certain events are far less commonly to do something else useful.
Generally, "post" triggers are used to do something useful.
Just about all DXL folks new to triggers end up writing a "pre module open" trigger that disallows the module from opening. Doh! That is a drag since the trigger is typically stored IN the module and it is difficult to remove until the module is opened. I went through this particular "right-of-passage" a few times.
Notice that a "pre module open" trigger does not have access to the "Module" since it is not yet open; and a post module close trigger no longer has access to the "Module" handle.
Typical "pre" triggers are pre-attribute-save triggers, preventing unauthorized changes to certain object-attribute values. In fact, this method of "locking down values" is far easier to manage than attempting to manage Object and Attribute-Value accesses. The trigger figures out if the value is locked down and whether you have rights, and prevents or allows accordingly.Note that pre-Dynamic triggers require a function that returns a boolen (permission for the event to occur) while post-Dynamic triggers use function with a void return.
Pre-Stored triggers use the "set(TriggerStatus)" function to allow or prevent triggers. I like this structure for pre-stored triggers:
- set (trigPreConPass) // event is allowed unless we figure out it should not below
- bla bla bla
- if (for whatever reason I want to prevent the event ) then set(trigPreConFail)
Priority
Not too useful, decides which trigger fires first when a single event will fire more than one trigger.
Unique
I think a trigger is "unique" based on its name and all its characteristics except the DXL. So if a pre-attr-save trigger priority 5 named "XZY" stored in Project X exists, you cannot create a new one. This has some implications on your definition code.
Manipulation
Some of the functions that take a Trigger parameter work when you are inspecting the trigger; others only work while the trigger is running. The manual does not clarify which is which. You can get the string scope(Trigger) when it is not running in the Definition code (or some other code) but can get the Object object(Trigger) inside the trigger code itself.
-Louie
Notes:
- Stored triggers require "C" access to the module or folder; removing requires "D" access.
- You cannot "modify" a trigger. You must delete it and then add it.
- On a side note: I don't recall the details but I had some serious issues with Triggers stored in a Project when that Project was subsequently converted into a Folder; or perhaps when it was converted back. I also had some issues when nested Projects each had defined triggers. I may have had some issues with restoring Projects with triggers defined.
- You can "turn triggers off" such that they do not fire; but they still fire unless the user is a DB-Admin. turning off does not prevent defining and deleting them.
- You will need to write some generic code that will find triggers and let you remove them individually; as often the original definition code turns up missing.
nice job Louie! ... my crayons are nearly worn out ...
Re: What does this statement?
AlexTidmarsh - Mon Jun 29 15:16:54 EDT 2015
